The following relates to the document presentation arts. It especially relates to presentation of documents in the extensible markup language (XML) format, and is described with particular reference thereto. However, the following is applicable to presentation of structured documents generally, including for example documents in XML, the standard generalized markup language (SGML), or so forth.
An advantage of using a structured document format such as XML is that the document can be validated as to whether it conforms with a standard schema. Some example presentation-focused XML schema that are presently in use include the W3C scalable vector graphics (SVG) schema, extensible hypertext markup language (XHTML), XML formatting objects (XML-FO), and so forth. Before the document is rendered, it is checked, or validated, by a suitable validation tool to ensure that the document conforms with the standard schema. The rendering engine is configured to properly render any document conforming with the standard schema.
Thus, for example, by validating before rendering an input document using a SVG validation tool such as RelaxNG or Schematron and a suitable schema, it can be assured that the document will be properly rendered by the SVG rendering engine. If the validation detects errors, these errors can be brought to the attention of a human publisher before rendering. The human publisher can then either modify the input document to correct the detected error, or go forward with the rendering in spite of the detected error.
Validation prior to rendering ensures that the document can be properly processed by the rendering engine. However, it does not ensure that the rendered document will conform with a presentation appearance desired by the document publisher. For example, the publisher may want to produce a brochure in which text is presented in three columns per page. The document may pass the validation tool but not satisfy the publisher's appearance requirements, for example if the document is in proper SVG format but includes only two columns per page. Validation occurs because nothing in the standard schema constrains the number of columns per page.
One option is to provide a more specific presentation-focused standard schema, for example requiring three columns per page. However, the goal of the standard schema is to balance between constraining the document presentation to ensure proper rendering, on the one hand, and providing the publisher with flexibility in selecting the presentation appearance, on the other hand. Presentation-focused standard schema such as SVG, XHTML, XML-FO, and so forth have generally been configured to maximize flexibility, so as to make the standard schema widely usable by a large cross-section of publishers. Including a specific constraint such as a specific number of columns per page would limit the usability of the standard schema.
Another option is to provide a number of a different standard schema conforming with the different presentation appearance objectives of different publishers. However, construction of a schema, or even modification of an existing schema, heretofore has been a laborious process suitably performed by highly skilled persons having extensive knowledge of non-intuitive low-level schema definition syntax. Applying such specialized expertise to generate a specialized standard schema targeting a small number of publishers may not be commercially viable. That is, a more specialized standard schema would have a smaller market, and thus would be less likely to be commercially successful.
Accordingly, the usual process is for the publisher to perform validation with a flexible standard schema such as SVG, XHTML, XML-FO, and so forth, and to render the document upon successful validation. The publisher then visually reviews the rendered document to detect deviations from the desired presentation appearance. If such deviations are detected, the document is modified and the validation and rendering repeated until conformance with the desired presentation appearance is achieved. This procedure takes a substantial portion of the publisher's time, may require multiple validation and rendering cycles, and is susceptible to human error. Moreover, the procedure must be repeated for each and every document that is validated and rendered. In applications in which the rendered document is ultimately physically printed, presentation errors that slip by unnoticed by the publisher can result in printing a large number of non-conforming, and perhaps useless, documents.